-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(hogql): placeholder expressions (part 1) #25091
Conversation
It looks like the code of |
9946448
to
553a7f5
Compare
553a7f5
to
08118e3
Compare
…nto placeholders-with-expr
f0317e4
to
bb3f072
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this makes sense, natural evolution of ast.placeholder
- the biggest nit here would be to remove all references of placeholders if we're totally moving to Blocks
type: Optional[Type] = None | ||
|
||
@cached_property | ||
def placeholder_chain(self) -> str | None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd return a list[str | int]
like a normal ast.Field(...).chain
- feels like this would be more aligned
def visit_block(self, node: ast.Block): | ||
# TODO: remove all this when we can use bytecode in placeholders | ||
if len(node.declarations) > 1: | ||
raise QueryError("Placeholders can only contain a single declaration") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: "Blocks can only contain a single declaration"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of the language mix of "block" and "placeholder" - especially with removing ast.Placeholder
node. I'd be in favour of removing all placeholder
references in favour of "block" here
@@ -40,6 +41,21 @@ class VariableDeclaration(Declaration): | |||
expr: Optional[Expr] = None | |||
|
|||
|
|||
@dataclass(kw_only=True) | |||
class Block(Expr): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having a util that creates a Block
from similar interface as a ast.Placeholder
could be nice:
def block_from_field_chain(chain: list[str | int]) -> ast.Block:
return ast.Block(....)
The biggest problem here is that it makes the parser a lot slower. Not substantially in my testing, but enough to cause a difference in CI --> one test that took 22min now times out at 30 😬. So work to do and alternatives to consider |
Problem
Pulls out the first chunk from #25040
Changes
ast.Placeholder
withast.Block
.ast.Placeholder(chain=["hogql_val_1"])
ast.Block(declarations=[ast.ExprStatement(expr=ast.Field(chain=["hogql_val_1"]))])
How did you test this code?
Updated a lot of tests. MyPy was my friend.